Data Dynamos Project Proposal

Authors

Sienna Sterling

Isabella Darko

Overview

This project focuses on the vital role of stylists, who curate the visual aesthetic of individuals, brands, and public figures by selecting and crafting outfits that shape how the world perceives them. Stylists are more than just fashion experts—they are artists who use clothing to tell powerful stories, influence trends, and create iconic looks. Our database will assist stylists in managing large wardrobes, streamlining the process of putting together cohesive looks, and reducing the challenges they face in their day-to-day work.

Deliverables

Problem Description

Problem Domain

A stylist is a professional who curates and crafts the perfect looks for individuals, brands, or public figures. They are the masterminds behind a person’s complete visual aesthetic, orchestrating not only what someone wears but how they wear it, to create a cohesive, striking image. More than just selecting outfits, stylists shape how the world perceives many of our favorite brands, celebrities, and influencers. Through their knack for design and creativity, they have the power to control and influence entire narratives, telling stories through fashion alone. These talented professionals are the unsung artists behind some of the most iconic and unforgettable looks in fashion history. With clothing as their medium, stylists bring their artistic vision to life, creating statements that not only define trends but also immortalize moments in culture.

Need

Our database is essential for stylists who manage numerous clients with extensive wardrobes. Given the vast amount of clothing celebrities receive through PR packages and events, it can be overwhelming to keep track of everything. This challenge is compounded by the difficulty of scheduling in-person fittings. Our database addresses these issues by providing a centralized platform where stylists can efficiently organize and access their clients’ clothing inventory. This system allows stylists to style clients remotely, reducing the need for physical meetings. Additionally, it helps combat overconsumption by ensuring that no piece of clothing is overlooked. Ultimately, our database streamlines the styling process, making it easier for stylists to manage their clients’ wardrobes effectively.

Context, Scope and Perspective

The fashion industry is a multi-billion dollar industry, comprised of many different components that work together to make it what it is today. Fashion is a collaboration between many talented models, designers, and stylists who come together to create looks that are, essentially, a form of art. Our focus is to specifically support the stylists, the creative minds responsible for shaping trends and helping people express themselves through style. While our goal is to tailor this to stylists, we truly believe that what we’re offering can be beneficial to anyone who’s interested in fashion or personal expression. It’s something we see as useful and accessible for everyone.

User Roles and Use Cases

User Roles

  1. Stylist (Primary User)
    • Needs: Stylists need an organized system to manage multiple clients’ wardrobes, including cataloging clothing and tracking outfits.
    • Use of Database: Stylists will log in to the database to add, update, or delete wardrobe items for each client. They can also browse clients’ inventories remotely, create outfit plans, and manage events. This eliminates the need for physical wardrobe inspections, allowing them to create style suggestions remotely and streamline the fitting process.
    • Interactions: They will frequently add new items to the database, tag them by category, and schedule appointments. They may also use data to provide clients with tailored looks for specific events.
  2. Client (Secondary User)
    • Needs: Clients need visibility into their wardrobe inventory curated by the stylist. They may want to preview outfits selected by their stylist and track clothing used in past events.
    • Use of Database: Clients will access a read-only version of their wardrobe inventory. They will be able to review outfits planned for upcoming events and provide feedback or make requests for alterations. This allows them to stay informed about their wardrobe without being physically present.
    • Interactions: Clients will log in to review their wardrobe and upcoming event outfits, as well as provide input or request specific items to be styled.
  3. Fashion Brand PR Team (Tertiary User)
    • Needs: Fashion brands often send new collections to stylists for their clients, and they need a way to track the clothing sent and whether it’s being used.
    • Use of Database: PR teams will have limited access to the system, allowing them to view which pieces from their collections are currently part of a client’s wardrobe. This ensures they can track the visibility and use of their clothing in public events.
    • Interactions: PR teams can log in to see if their garments are actively being styled or are part of planned outfits for high-profile events.

Use Cases

  1. Stylist Managing Wardrobe Inventory
    • Stylists can add new pieces from PR packages, categorize them (e.g., casual, formal, seasonal), and tag them by client. They can access the database on-the-go, allowing real-time updates during fittings or client meetings.
  2. Stylist Creating Outfit Plans
    • Stylists can browse a client’s inventory, select multiple pieces, and save outfit suggestions. These plans can be linked to specific events (e.g., award shows, photoshoots) and shared with the client for review and approval.
  3. Clients Viewing Outfits and Pieces
    • Clients can view outfits that have been assembled to find something to wear, and view indivdual pieces to see what’s in their closet.

Database Connectivity:

The database will be connected to:

  • Fashion Brand Platforms: Allows easy import of new collections and clothing lines from fashion brands.
  • Web Application: Stylists and clients will be able to access the database via a web application, ensuring on-the-go wardrobe management.

This approach will enhance collaboration between stylists, clients, and fashion brands, while reducing inefficiencies in the wardrobe management process.

Security and Privacy

To ensure the utmost privacy and security, our database design will prioritize safeguarding sensitive client information, especially when dealing with celebrity clients whose contact details and personal data require strict confidentiality. Given that many stylists will have access to this information, implementing robust security measures is essential to maintain client trust and protect their privacy.

Database Design

Entity-Relationship Diagram (ERD)

erDiagram
    
    STYLIST {
        int stylistID
        string name
        string experienceLvl
        string contact
    }
    
    CLIENT {
        string clientID
        string name
        string contact
        string shirtSize
        string pantSize
        string shoeSize
    }
    
    OUTFIT {
        int outfitID
        string name
        date dateCreated
        string style
    }

    PIECE {
         string piID
         string type
         string color
         string size
         string material
         string brand 
    }

    STYLIST ||--|{ CLIENT : "has"
    STYLIST ||--|{ OUTFIT : "makes"
    OUTFIT }|--|{ PIECE : "contains"

Relational Schemas

Stylist

Stylist(stylistID [PK], name [NOT NULL], experienceLvl [NOT NULL], contact [NOT NULL])

Key Variable Type Domain Constraint
PK stylistID INT Positive integers PRIMARY KEY
name VARCHAR(100) Text up to 100 chars NOT NULL
experienceLvl VARCHAR(100) 1-12 (Beginner, Intermmediate, Expert) NOT NULL
contact VARCHAR(100) Valid email format NOT NULL, UNIQUE

Client

Client(clientID [PK], name [NOT NULL], contact [NOT NULL], shirtSize [NOTNULL], pantSize [NOTNULL], shoeSize [NOTNULL])

Key Variable Type Domain Constraint
PK clientID INT Positive integers PRIMARY KEY
name VARCHAR(100) Text up to 100 chars NOT NULL
contact VARCHAR(100) Valid email format NOT NULL, UNIQUE
shirtSize VARCHAR(6) 1-6 (Small, Medium, Large) NULLABLE
pantSize VARCHAR(6) 1-6 (Small, Medium, Large) NULLABLE
shoeSize VARCHAR(6) 1-6 (Small, Medium, Large) NULLABLE

Piece

Piece(pieceID [PK], type [NOT NULL], color, material, brand, size)

Key Variable Type Domain Constraint
PK pieceID INT Positive integers PRIMARY KEY
type VARCHAR(50) Clothing types (e.g., top, bottom) NOT NULL
color VARCHAR(30) Standard color names NULLABLE
material VARCHAR(50) Materials (e.g., cotton, polyester) NULLABLE
brand VARCHAR(50) Text up to 50 chars NULLABLE
size VARCHAR(6) 1-6 (Small, Medium, Large) NULLABLE

Outfit

Outfit(outfitID [PK], stylistID [FK], style [NOT NULL], dateCreated [NOT NULL])

Key Variable Type Domain Constraint
PK outfitID INT Positive integers PRIMARY KEY
style VARCHAR(50) Formal, casual, steetwear etc. NOT NULL
dateCreated DATE YYYY-MM-DD format NOT NULL

OutfitPiece

OutfitPiece(outfitID [FK], pieceID [FK])

Key Variable Type Domain Constraint
FK outfitID INT Must exist in Outfit FOREIGN KEY REFERENCES Outfit(outfitID)
FK pieceID INT Must exist in Piece FOREIGN KEY REFERENCES Piece(pieceID)

StylistClient

StylistClient(stylistID [FK], clientID [FK])

Key Variable Type Domain Constraint
FK stylistID INT Must exist in Stylist FOREIGN KEY REFERENCES Stylist(stylistID)
FK clientID INT Must exist in Client FOREIGN KEY REFERENCES Client(clientID)

Functional Dependencies and Normalization

Step 1: Identify Functional Dependencies

For each table, we’ve identified the functional dependencies, which describe how one attribute depends on another:

  • Stylist:
    • Functional Dependencies: stylistID → name, experienceLvl, contact
    • Explanation: stylistID uniquely determines all other attributes in the table, with no additional dependencies, so this table is already in BCNF.
  • Client:
    • Functional Dependencies: clientID → name, contact, shirtSize, pantSize, shoeSize
    • Explanation: clientID uniquely determines each attribute in the Client table, meaning that no further decomposition is needed for BCNF.
  • Outfit:
    • Functional Dependencies: outfitID → name, style, dateCreated
    • Explanation: In the Outfit table, outfitID determiens all other attributes, so no additional dependencies exist, keeping the table in BCNF.
  • Piece:
    • Functional Dependencies: pieceID → type, color, size, material, brand
    • Explanation: Each attribute is fully dependent on pieceID, meaning this table is already in BCNF.

Step 2: Normalize to BCNF/4NF

Each table satisfies BCNF because:

  • All tables have a single primary key that uniquely determines all other attributes, which is the definition of BCNF. There are no partial dependencies.
  • Every functional dependency in each table has a super key as its determinant.

Step 3: Lossless Decomposition

In this case:

  1. Stylist, Client, Outfit, and Piece tables already meet BCNF requirements without any more decomposition. The relationships between tables (like StylistClient and OutfitPiece) allow us to maintain a lossless structure.
  2. Relationship Tables:
    • StylistClient: This associative table with stylistID and clientID as a composite primary key satisfies BCNF/4NF since each combination of stylist and client is unique.
    • OutfitPiece: This table has a composite primary key with outfitID and pieceID, meaning no redundant data or multi-valued dependencies exist. It also meets BCNF/4NF requirements.

The database schema is structured so that any data split across the tables can be recombined by joins on primary and foreign keys, achieving a lossless decomposition.

Conclusion

This schema is fully normalized to BCNF. All tables and associative tables meet these forms By following the normalization process step-by-step, we ensured that the design satisfies the requirements for an efficient, well-structured database that can be expanded or modified with minimal risk of issues.